Module 1 Closure
Spring 2006
Question:
I read in chapter one about the two different types of projects in relationship to their life-cycle curves. The author used the analogy of a chocolate cake and how it changes from ‘goop’ to ‘cake’ in a matter of minutes inside the oven. I guess my question deals with how you know what type of project you’re dealing with before the project begins. How do I know if I’ve got chocolate cake or apple pie? If you’ve dealt with enough projects, you could probably make a pretty good assertion as to the nature of the project. But what if you’re young and new to the entire business of project management. How do you eliminate the potential snares?
Kinney’s Answer:
This refers to the slow start, quickening and then rapid completion form of life cycle (Figure 1-5). In my experience, this pattern is not common but less rare than you might think. In my experience, that pattern is more a reflection of inadequacies in our ability to measure certain kinds of progress than anything else.
First, if you’re dealing with most construction projects, you are unlikely to see that pattern. These involve progress, and in fact, some projects are contracted with “progress payments” made for work performed (civil earthwork projects are often done that way). Those are examples of the S-curve pattern.
As for the other pattern, the most appropriate example might be a very small job which has to be planned and engineered, but which is implemented quickly and has no closeout requirements. (The closeout documentation is what drags the finish out.) The other type of example I can think of involves process shutdown work, such as refinery/topping unit turnarounds or pipe replacement. On the Trans-Alaska Pipeline, we occasionally have to replace an in-service 48” gate or check valve. This involves a great deal of pre-work – planning, specification, procurement, procedures, getting hot tap and stoppling equipment in place, equipment and tool staging, etc. The actual changeout is done over maybe a 36 hour period with tight time parameters to each stage of operation. So the big physical work is completed rapidly; beforehand, what you have is a lot of prework but no results to show for it in place.
The authors mention computer software projects as another example of something with a lot of background work that really comes together in useable form rapidly and toward the end. I have what seems to me a conceptually similar example. Last year, we had a massive project to improve and accurately map 223 remote containment sites along the TAPS corridor. Along with the mapping, we had to specify appropriate containment tactics and equipment, and identify where the equipment would come from. If inadequate, we had to specify additional materials. The actual field work followed a very conventional S shaped model per Figure 1-3. But the mapping and tactics work was very much the rapid-completion model of Figure 1-5. It took a long time to get the base maps prepared and scrubbed, worked and reworked to a useable form, but when the last elements came together, they turned base material into final material at an incredible rate.
I think the examples I listed are pretty unusual, but they are interesting to be a part of. What you’re far more likely to see is the kind of work that can be planned as a series of subtasks, such as a building project. You can estimate craft progress with Means Construction Data or some such thing; for example, floor slab can be estimated as taking a certain amount of time per, say, 1000 square feet. Once that task is done, another key increment of progress is done and it’s on to the next thing. This goes on as resource availability and space constraints draw out progress. And typically you finish slow, because for every such job there is a punchlist, which takes time to work through.
One last comment: if you do find yourself with a job matching the second pattern, don’t expect that the project costs are going to track with the project completion pattern metric. The billable hours rack up with little outwardly showing until it all (hopefully) coalesces.
Question:
I wanted to clarify that a program is comprised of many projects. For instance, the NASA Lewis Research Center is working on a new space shuttle program. Each system on the shuttle is it’s own project: The hydraulics project, the electronics project and the mechanical project. These projects are part of the shuttle program. Or I suppose the shuttle program could be a shuttle project comprised of special tasks – hydraulics, electronic, mechanics. How do you delineate the hierarchy? Or when does a task become a project?
Kinney’s Answer:
The term “program” has different meanings to different organizations. In my company, Alyeska, a program is something that recurs year after year. For example, every year we have to do investigations of anomalies found in pipeline pigging data, particularly the corrosion pigs. So we have to do digs. There’s some engineering in this (particularly related to excavation and pressure parameters), but mainly it is project coordination, execution and field inspection to a standard package. In a sense, we can think of that kind of a program as an ongoing series of similar projects.
I like the definitions found in the PMI Guide to the Project Management Body of Knowledge (PMBOK):
As for “tasks,” that term varies as well. I am used to using the term in connection with elements of the work breakdown structure. For example, mobilization might be a task. Procurement might be a task, with valve procurement being one subtask, stoppling equipment being another, etc. Meredith and Mantel say that a task is “a subset of the project, consisting of work packages.” I personally like that definition. (I don’t like what PMBOK says, which is that a task is “a generic term for work that is not included in the work breakdown structure but potentially could be a further decomposition of work by the individuals responsible…” )
When does a task become a project? This is entirely a function of the choices an organization makes and the scale of changes being contemplated. In our TAPS Reconfiguration program, there are many large projects. And some of those projects have associated task packages that involve huge amounts of work in their own right. If these tasks weren’t done in the context of larger changes, it would make perfect sense to treat them as stand-alone projects. But since they are only being done because lots of other things are also being done, it makes sense to coordinate these, and to manage them together in the context of the large projects.
I mentioned PMBOK, and I will often be doing so throughout the class. I recommend each of you to consider becoming certified as a Project Management Professional (PMP) because an increasing number of companies are viewing this favorably as an employment credential. This certification, awarded by the Project Management Institute, is based on your command of PMBOK as reflected in an exam.
Question:
My question to you would be about the Government and project management.
Being part of the US Army Corps of Engineers I can see the history and usefulness of the project management system and the book explained how it was born in the military. Now that the private sector and market forces have had their chance to chew on it, what changes do you think have been important? Do you think private firms have become “better”?
I inclined to believe private firms can be cheaper, more efficient but I don’t believe the US Government could or should market the kind of project work the Corps and military does out to the lowest bidder.
Kinney’s Answer:
I’ve been fortunate to have had professional experience on several sides of the fence – in the public sector (local government) and the private sector (construction contractors, engineering consultants – including doing my own thing – and in industry). Each of these entities has different interests and differing missions, and misunderstanding of the others abounds. (I’m sure I will write more about functional balkanization at a later date.)
The Army COE is part of the Army and has civilian mandates as well (such as administration of wetlands programs and doing flood control work). As I see it, the Army itself does not have “efficiency” as its central goal. Rather, effectiveness is its goal – the Army’s goal is to fight and win America’s wars. If the machine is inefficient, that is in many ways a collateral price to be paid for the redundancy it takes to assure the kinds of effective outcomes the military is designed for.
Yes, it can all become contaminated with politics, but it is always good to remember that the military’s mission is not the same as what a private contractor’s mission is. Thus, the original development and use of project management tools was done to organize work and thus maximize the chances of an effective end product being produced within the time required for delivery under wartime or other critical conditions. The critical path method clearly is a tool toward efficiency of scheduling, arising from the military interest in the scheduling problem; it didn’t really originate as an application oriented to commercial use. But it certainly has been developed by the private sector to that end, not only in R&D and construction, but in arts and entertainment, software development and other applications. So I would say that the market forces have really expanded both the usability of such methods and the usefulness to a wide array of problems. It has helped us all out. (There is, in fact, a trend toward “projectized” organizations where the majority of people are devoted to projects throughout their lives: this is applicable particularly to technology and consumer products companies who require an ongoing stream of new product introductions with short development cycles and market cycles.)
With respect to the contracting issue, my comments are these: as a taxpayer, my values dictate that I’m interested in seeing efficiency and wise use of expenditures. To that end, it appears that privatization can be a valuable tool. But as we read about, and I’m sure you experience, privatization can backfire in a number of ways. I don’t have sufficient knowledge to know what work should be done by the Corps and which should go out to bid, but I will venture this: at the very least, my view is that overall project management should be a management function retained by the Owner and not farmed out. I know there are modest success stories of contracted project management – the Municipality of Anchorage has contracted portions of its process for years – but ultimately the Owner has to have people on staff who are one with the Owners’ interests, who aren’t conflicted in their roles. That’s my view, but I would sure be open to hearing the other side.
Dr. Perkins also points out that there is another issue for all public contracting. That is to prevent corruption and encourage people’s faith in the integrity of the process. That is very different than private procurement, where value is usually the only consideration. Hence the public procurement must be transparent and demonstratively fair to all who make an offer.
Question:
The text indicates: “Recent research indicates that performance and schedule are more important than cost during “all” stages”, (15). Although performance and schedule are important, isn’t concern with cost at project’s end vital to the contracted company? High overtime costs and expedited shipping have bankrupt many attempting to keep a schedule.
Kinney’s Answer:
First, to frame up the issue: the accepted view of project success is that involves satisfaction of the “triple constraint” formed by scope (a/k/a “performance”), schedule and budget.
Harold Kerzner adds the fourth leg to this three-legged stool by stating that it has to be done “within good customer relations”; your book says much the same thing (p. 3) referring to meeting client expectations (although there is a crucial difference: “meeting expectations” can falsely imply satisfaction of all expectations, wishes or whims; really, you have to focus on the end product that will meet acceptability criteria). Client satisfaction is a critical point, because I’ve seen many projects that have ended up alienating clients by being framed narrowly in the interest of project success rather than long term client success.
But I digress. What Meredith and Mantel are talking about is the tradeoff between performance, schedule and budget which can occur in all project phases. They discuss this concept more thoroughly in Section 3.2 under the header “Making Project Goal Trade-offs.”
This is worth reading but, for me, their explanation is somewhat incomplete.
From my viewpoint, the issue you raised is extremely important, not only for the client but the contractor as well. It begs the question: how can anyone justify running oneself into potential bankruptcy by losing focus on costs?
The answer is: you can’t, and fortunately that’s not what they’re saying.
For every phase of the project – every task, every significant step in the work breakdown structure – you have to set up a schedule, a resourcing plan and a cost associated with those resources. Because of the fact that projects inherently produce unique end products, there is great uncertainty on schedules and budgets, particularly early on when the best you can do is “rough order of magnitude” (ROM) guesses based on judgment and experience. Later, as the scope is engineered in, costs can be better estimated. But there is still considerable uncertainty, and I doubt you can ever do much better than, say, +/-10%.
The cost tradeoff is a tradeoff relative to the budgeted amount in the work breakdown structure. A good example of an early-phase tradeoff is the realization that more upfront effort in developing tight project specifications and planning will result in improved delivery schedules in implementation. Yes, you blow your Phase I engineering budget and maybe your schedule will slip a little too. But it pays itself off handsomely with much smoother installation and lower costs later on, and the result is a lower overall project cost, in addition to meeting the schedule and scope.
This kind of beneficial tradeoff could happen more often than it does. But often managers focus on tight control of the project cost at every phase, squelching the extra effort to solve problems early, not realizing that the result may be bite-back later on. (The other thing to recognize is that resources to pile onto projects are not unlimited, whether in the early going or later on.)
There’s one more cost tradeoff that comes up more often than anyone would like. You sometimes have to sacrifice cost for performance and schedule at the end of a project. It hurts to blow your budget then, and usually you’re already over the overall budget. Why would you do it, then? To avoid even more pain. What you sometimes have to do is throw in the extra resources just to get it all over with and to cut your losses. At that point, a project has really gone sour, but you really have no good options – and, alas, bankruptcy can be the result.
Question (condensed from original):
Why is it that some projects takes forever to finish? (Referring to the S-shape in figure 1-3)…[although project completion is correlated with cost and resources], sometimes there are resources to finish the project, but it just takes forever to do it.
Kinney’s answer:
Clearly there are psychological and motivational factors involved in work completion. Closeout work is generally cleanup work, both in the field (correcting the punchlist items) and the office (completing and filing documentation, etc.). It isn’t glamorous. Usually while you were working on the project, a lot of other work piled up behind it. You really have the feeling that the train has left the station, and you want to move on to the next thing. The energy and momentum of your organization is no longer with the old project, it’s on the next thing, which is where the money is to be made or saved now. I’ve experienced this letdown many, many times and have come to view it as simply a natural part of the project cycle. But it’s in your own and your organization’s best interest to tough out the last parts of work, and to try to compress the finish as much as you can, so that the job truly is behind you. Just know that your peers aren’t necessarily going to be with you – they move on just as you are inclined to.
But the motivation and psychology both arise from the fundamental reality that you – as a project manager, project engineer or other team member – are a scarce resource and that there are other priorities that are demanded of you. So it is natural, and required, to make that switch to the next project as quickly as possible. After all, the earlier you get involved with the next project, the more influence you can have on the project’s success.
Thus, project closeouts are inevitably needed, but inevitably have to compete for scraps of time. This is really a systems problem, and that’s the key to understanding the slow finish phenomenon.
Question (condensed from original):
Is figure 1.5 lying?
Anyone who solved Rubik’s cube knows that just a few moves (about 10) before the cube is finished it looks like mosaic. It is chaos. Is this an example of exponential percent completion of the project?
I don’t think so. In fact, as a rough estimate, it takes about 500 moves to complete the cube. 10/500 is 2 %. So when 10 moves remains the cube is to 98% solved despite the fact that the “client” may not aware of that fact.
How should the completion of a project be judged?
Kinney’s answer:
I like the analogy, because I used to solve Rubik’s Cube myself. I was obsessed with it (around 1982) and, after finally solving it, I got pretty good at it (consistently a minute or less, though today I can’t solve it to save my life).
On the other hand, I read back then about kids that wired the solution down to 6 to 10 seconds on a routine basis. In addition to phenomenal eye-hand coordination, this would require a very efficient “algorithm” (for want of a more appropriate term) in the form of sequencing your turns to achieve the desired grouping. I never had patience for reading the books that came up with the formulas indicating color face and clockwise/counterclockwise moves. But cube solution (which, whether you know it or not, is an application of group theory) requires that form of algorithm organization and sameness leading to more moves in the solution than were involved in the initial scrambling.
Such is the nature of it: in the case of the cube, you have to judge completion relative to the process required for solution rather than the process that led to its current state. And that’s not just true of the cube. It’s true of just about anything.
Think of it in thermodynamic terms: the scrambled state represents a state of entropy, and more work (maybe much more work) is required to lower the state of entropy into the unscrambled state. This is true not only for Rubik’s Cube but for most other things in life.
One other comment: completion of a project can be judged a number of ways. As noted above, the Figure 1-5 pattern (accelerated progress at the end) reflects completion as a function of completed end deliverables which really only achieve value at the end. This is an “earned value” philosophy. But completion can also be defined in terms of level of effort and man-hours which is required to produce that end value. The problem with that definition is that it doesn’t lend itself to measurement, except perhaps in retrospect. If you are the owner paying the bill, for all you know, the project team is doing nothing but drinking coffee if there’s no end product to show for it. That’s why it often takes a good relationship with a trustworthy partner before you’ll agree to pay some vendors by billable hours rather than by milestone or progress.
Project completion status is an imperfect art. If you’re in engineering or management, you will often be asked to judge your % complete and you’ll give a number, often based more on subjective judgment than anything else. This is OK, especially when there is no better way to do it, but just remind them that you’re guessing. And, of course, always be straight-up about what is and isn’t done.
Question:
My comment to module 1 is regarding organizational structure and complexity. I understand that if a organization has a lot of different projects it can be more complex, but without forming a defined project / project group I would think that there might be even more confusion within the organization on what to do (example: people does not know who has the responsibility for all the different things that are supposed to be done).
Kinney's Answer:
You’ve just gotten to the heart of why project groups exist.
There is nothing new under the sun, and projects are definitely nothing new. The Great Pyramid is the example that always comes up. Projects weren’t born in World War II; what did happen then was that better methods of organizing and managing them were created.
Project groups provide a clear mechanism for getting things done, and that’s why they are useful. When I worked as a facility engineer, we did many small projects (modifications, etc.) on a local level. This made sense as fill-in work. But whenever we tried to take on something larger scale than we could do, given our limited resources and budgets and competing operation/maintenance priorities, the results were greatly protracted schedules and higher costs. We got bruised. On the other hand, I looked around and saw some of my peers lose their jobs because of projects that really went south (e.g., jobs that were essentially designed by change order).
Having a separate projects organization has disadvantages – it creates a functional division and silo effect. It is inherently bureaucratic. And projects do not give the answer to all your problems – handling simple maintenance within a project model creates large overhead costs and inefficiencies that are not appropriate at all. But for sizeable missions, nobody has proposed a better approach, which is why we do it.
Question:
My question is about project life cycle found in 1.3 (Figs. 1/6 and 1/7): My question is not how does the rate-of-project-progress chart work, rather it is: Where does one choose a project-specific chart for different projects?
Kinney's answer:
This kind of chart is actually an "earned value" chart, which is more fully described in Chapter 10. See Figure 10-6 for an example. The earned value is the value of completed work throughout the project, and represents generally the progress that you actually get paid for. What is instructive about the earned value is that it can be compared to the "planned value" - how much you were supposed to have earned up to this point. The difference between earned value and planned value is known as "schedule variance" as the figure shows.
That's where this comes in, and it's a very powerful tool that, surprisingly, seems poorly understood by a lot of competent project managers who would benefit from it.
In terms of selecting an earned value chart - well, you don't really select it, you plot it based on actuals. You do have design input into the planned value, but that should be an artifact of your estimated progress as estimated from your GANTT chart and progress projections.